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(54) Hierarchical database 

(57) A hierarchical database, in which a lower class 
inherits to a property of an super class, having a class 
code for each class to identify the class, includes a first 
classification system having a regular class, and a sec- 
ond classification system having the regular class and 
a synonymous class referring to and using the regular 



class of the first classification system, wherein the syn- 
onymous class has an identification information to iden- 
tify it is the synonymous class, a class code of the syn- 
onymous class, and a class code of the regular class of 
the first classification system to which the synonymous 
class refers. 
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Description 

[0001 ] The present invention relates to a hierarchical 
database management system, a hierarchical database 
management method and a hierarchical database man- 
agement program which manage a hierarchical data- 
base. 

[0002] In versatile operating systems (OSs) such as 
an Microsoft Windows (registered trademark), UNIX 
(registered trademark) or LINUX (registered trade- 
mark), a tree view has been adopted as a graphical user 
interface (GUI). A tree-like directory structure or file 
structure is visually presented to the user by the tree 
view so that the user can navigate to a specific directory 
or file. 

[0003] In respective nodes in the tree view, however, 
there in no relationship such as an inheritance relation- 
ship or an inclusive or subset relationship between in- 
formation included in a high-order node and information 
included in a low-order node. Nodes prefixed by a root 
node in the tree just indicate that holders for information 
such as files, i.e., containers, are connected with each 
other in a tree form. This kind of structure is referred to 
as "hierarchical directory structure 0 in the description of 
this specification, and it is differentiated from a hierar- 
chical database in this specification. In the present in- 
vention, a unit of information that characterizes a class 
and is associated with the class is referred to as a "prop- 
erty", and each information field or element that consti- 
tutes the information structure of the class or property 
is referred to as an "attribute". 

[0004] On the other hand, a database as typified by 
an object-oriented database (OODB) or an object-rela- 
tional database (ORDB) has a hierarchical structure in 
which a sub-class in herits to a property of a super class. 
In this database, the property increases progressively 
in the sub-class in accordance with inheritance. Here, 
the "inheritance" means the transmission of the proper- 
ties of super class into its sub-class(es). Such a tech- 
nique is described in, e.g., "Object-oriented Concepts, 
Database, and Applications", edited by Won Kim, 1989, 
ACM Press and many other references. Further, in the 
object-oriented database, a classification in a hierarchy 
is often called "class". On the other hand, in the object- 
relational database (ORDB), a table which has allowed 
inheritance corresponds to the inheritance, and a lower- 
order table inherits to a property from a high-order table 
between tables having hyponymy. That is, a lower-order 
table inherits header information of a column constitut- 
ing a high-order table. In this specification, OODB and 
ORDB collectively mean "hierarchical database". Data 
having the same property type belonging to the classi- 
fication of respective hierarchies is referred to as an "in- 
stance", and a set of such data is referred to as "popu- 
lation". A population of data is stored in a structure which 
is usually referred to as a table in a relational database 
(RDB) or ORDB. In a table, a line of properties consti- 
tuting the table is called a header of the table. 



[0005] A hierarchical database having a hierarchical 
structure as typified by an object-oriented database in 
which a sub-class inherits a property of a super class 
has a structure in which the property increases progres- 
5 sively in the sub-class in accordance with inheritance. 
Therefore, in case of setting an import of a specific prop- 
erty from a class in one dictionary 1 to a class in an other 
dictionary 2 or a multiple inheritance of all properties, a 
sub-class in a classification system of dictionary 2 in- 
fo herits an imported class property of dictionary 1 . In this 
case, generally, a sub-class which is equal to or inferior 
to the above-described class in the classification system 
in dictionary 2 is affected by revision of a definition of 
the corresponding property in dictionary 1 . Furthermore, 
/ 5 when complying with IS0 1 3584 Parts Library standards 
Part 24 (standards - volume No. 24), in character string 
type properties having language dependent values, 
identity between properties whose values can be written 
in multiple languages is essentially determined by codes 
20 which do not have linguistic meanings. Therefore, when, 
e.g., classes are implemented as tables in a database 
in accordance with the ISO 13584 standards, whether 
two classes are the same type must be judged by using 
codes in headers of the tables (alignments of properties) 
25 which are not dependent on the usual linguistic seman- 
tic interpretation (rather than codes in which character 
strings have regular linguistic meanings as typified by, 
e.g., "Product name"). 

[0006] When classes having the same concept exist 
30 in two standard classification dictionaries, it is normal in 
a conventional example that one dictionary issues 
codes irrespective of the other dictionary, and a GUI 
symbol as a class reference to another class in another 
dictionary is provided in a database storing both diction- 
35 aries so that reference from one dictionary class to the 
other dictionary class is indicated. As many GUI sym- 
bols, the same icons as folders or directories are used. 
Problems of this example are as follows. 

40 (j) First, when these dictionaries are treated as a 
simple link which does not have a property inherit- 
ance relationship at all, the revision of the property 
definition can be independently carried out between 
one dictionary and another. If this revision of the def- 

4£ inition is allowed, types and definition contents of 
properties of classes in both dictionaries become 
far different with time. As described above, it is hard 
to stabfy share the same concept between two 
classes in the two standard classification dictionar- 

so ies. Moreover, when class names are given in mul- 
tiple languages in one dictionary, reference to an- 
other class in another dictionary which also uses the 
same or different set of languages cannot be real- 
ized with a simple link mechanism which directly 

55 links a class name in one language to another class 
name in another language, unless a special func- 
tion to search for a translated name related to the 
linked class corresponding to the language of the 
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referencing class, or a translation mechanism from 
the language of the linked class to the language of 
the referencing class is provided. 

On the other hand, when this reference rela- 
tionship is treated as an inheritance relationship, 
there is the following problem, 
(ii) A class in one dictionary inherits properties of a 
class in the other dictionary. As a result, the similar- 
ity of the classes in both dictionaries is maintained, 
but one dictionary is affected by the revision of the 
property definition of the other dictionary. For exam- 
ple, when a property is added to a class in one dic- 
tionary, a structure of the database must be 
changed and the property must be added in a class 
of the other dictionary making reference to the 
former class. Of course, in this case, both classes, 
property identification codes and others must be 
matched with each other. 

[0007] In a conventional hierarchical database man- 
agement technique, when two standard classification 
dictionaries have classes having the same concept, it is 
normal to provide a GUI symbol as a class reference to 
anther class in another dictionary so that reference from 
one dictionary class to the other dictionary class is ex- 
pressed. 

[0008] However, in case of treating reference to class- 
es as a simple link which does not have a property in- 
heritance relationship at all, types or definition contents 
of properties of both classes become far different with 
time, and it is hard to stably share the same concept 
between the two classes in two classification dictionar- 
ies. 

[0009] Additionally, when a reference relationship be- 
tween two classes in two dictionaries is treated as an 
inheritance relationship, since a class in one dictionary 
inherits a property of a class in the other dictionary, the 
similarity of the classes in both dictionaries can be main- 
tained. However, one dictionary is affected by the revi- 
sion of the property definition of the other dictionary. In 
this case, dictionary revision work becomes complicat- 
ed. 

[0010] It is an object of the present invention to pro- 
vide a hierarchical database management system, a hi- 
erarchical database management method and a hierar- 
chical database management program which facilitate 
management between classes in a hierarchical data- 
base. 

[0011] According to an aspect of the present inven- 
tion, there is provided a hierarchical database, in which 
a lower class inherits to a property of an upper class, 
having a class code for each clasfffo identify the class, 
comprising: a first classification system having a regular 
class; and a second classification system having the 
regular class and a synonymous class referring to and 
using the regular class of the first classification system, 
wherein the synonymous class has an identification in- 
formation to identify it is the synonymous class, a class 



code of the synonymous class, and a class code of the 
regular class of the first classification system to which 
the synonymous class refers.. 

[0012] The present invention is not restricted to the 
5 system, but it can be achieved as a management meth- 
od or a program applied to this system. 
[0013] This summary of the invention does not nec- 
essarily describe all necessary features so that the in- 
vention may also be a sub-combination of these de- 
10 scribed features. 

[0014] The invention can be more fully understood 
from the following detailed description when taken in 
conjunction with the accompanying drawings, in which: 

15 FIG. 1 is a view showing an example of a GUI used 
in a hierarchical database management system ac- 
cording to a first embodiment of the present inven- 
tion; 

FIG. 2 is a conceptual view showing a hierarchical 
20 structure of classes and properties of each class ac- 
cording to the first embodiment; 
FIG. 3 is a view showing an example of a structure 
of the hierarchical database management system 
according to the first embodiment; 
25 FIG. 4 is a view showing an example of display of 
a class tree presented to the user according to the 
first embodiment; 

FIG. 5 is a view showing an example of a storage 
format of types of classes stored in a dictionary in- 
30 formation storage portion according to the first em- 
bodiment; 

FIG. 6 is a view showing an example where synon- 
ymous classes are displayed in another window ac- 
cording to the first embodiment; 
35 FIG. 7 is a view showing an example where a code 
of source class is displayed by using a balloon ac- 
cording to a second embodiment of the present in- 
vention; 

FIG. 8 is a view showing an example where a syn- 
40 onymous class is displayed in a balloon according 
to the second embodiment; 
FIG. 9 is view showing a display example of a class 
tree display portion according to the second embod- 
iment; 

45 FIG. 10 is a view showing a display example of class 
tree display portion according to the second embod- 
iment; 

FIG. 1 1 is a view showing an example of a class tree 
according to a third embodiment of the present in- 
50 vention; 

FIG. 12 is a view showing a description example of 
dictionary information according to the third embod- 
iment; 

FIG. 1 3 is a view selectively showing a part in which 
55 class information in a Part21 file is written according 
to the third embodiment; 

FIG. 1 4 is a view selectively showing a part in which 
class information in a Part21 file is written according 
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to a fourth embodiment of the present invention; 
FIG. 1 5 is a view showing a description example of 
synonymous classes according to a fifth embodi- 
ment of the present invention; 
FIG. 1 6 is a view showing a description example of 
the synonymous class according to the fifth embod- 
iment; 

FIG. 1 7 is a view showing a description example of 
the synonymous class according to the fifth embod- 
iment; 

FIG. 1 8 is a view showing an example of a descrip- 
tion of synonymous classes according to a sixth em- 
bodiment of the present invention; 
FIG. 1 9 is a view showing a description example of 
EXPRESS-G including associative entities accord- 
ing to the sixth embodiment; 
FIG. 20 is a view showing an example where a 
Part21 file is written by using extension entities de- 
picted in FIG. 1 9 according to the sixth embodiment; 
FIG. 21 is a view illustrating a description of synon- 
ymous information according to a seventh embod- 
iment according to the present invention; 
FIG. 22 is a view illustrating description of the syn- 
onymous information according to the seventh em- 
bodiment; 

FIG. 23 is a view illustrating a description of the syn- 
onymous information according to the seventh em- 
bodiment; 

FIG. 24 is a view illustrating a description of the syn- 
onymous information according to the seventh em- 
bodiment; 

FIG. 25 is a view showing a display example of a 
synonymous class according to an eighth embodi- 
ment of the present invention; 
FIG. 26 is a view showing a flowchart of a synony- 
mous class display operation according to the 
eighth embodiment; 

FIG. 27 is a view illustrating an automatic conver- 
sion function according to a ninth embodiment of 
the present invention; 

FIG. 28 is a view showing a relationship between a 
synonymous class and source class according to a 
tenth embodiment of the present invention; 
FIG. 29 is a view showing various kinds of informa- 
tion of a class according to an eleventh embodiment 
of the present invention; 

FIG. 30 is a view showing an example of a GUI 
which associates two content table views with each 
other according to the eleventh embodiment; 
FIG. 31 is a view showing a display example of a 
content table view according to the eleventh em- 
bodiment; 

FIG. 32 is a view showing an example of a GUI 
which is used to register a content table view ac- 
cording to the eleventh embodiment; 
FIG. 33 is a view showing an example of a setting 
file which is used to register a content table view 
according to the eleventh embodiment; 



FIG. 34 is a view showing a screen display example 
for a concrete setting of a synonymous class ac- 
cording to a twelfth embodiment of the present in- 
vention; 

5 FIG. 35 is a view showing an example of a synon- 
ymous setting portion according to a thirteenth em- 
bodiment of the present invention; 
FIG. 36 is a view showing an example of a display 
screen according to a fourteenth embodiment of the 

w present invention; 

FIG. 37 is a view showing an example of screen dis- 
play according to a fifteenth embodiment of the 
present invention; and 

FIG. 38 is a view showing an example of a MY FA- 
'S VORITES setting file according to the fifteenth em- 
bodiment. 

[0015] Embodiments according to the present inven- 
tion will now be described hereinafter. 

20 

(First Embodiment) 

[0016] FIG. 1 is a view showing an example of a GUI 
used in a hierarchical database management system 

25 according to a first embodiment of the present invention. 
FIG. 1 shows an example of a GUI which displays a hi- 
erarchical tree (a class tree), a classification (a class) 
and a property. When a class is selected from a class 
tree display portion 1 01 , class information such as class 

30 code which identifies a class, a definition, a note, a ver- 
sion and others is displayed in a class information dis- 
play portion 102. A property list display portion 103 dis- 
plays a list of properties which can be used in that class. 
[001 7] FIG. 2 is a conceptual view showing hierarchi- 

35 cal structure of classes and properties of each class. A 
sub-class inherits a property of a super class. Therefore, 
when each class has properties as shown in FIG. 2, for 
example, class T05: Desktop PC" inherits the following 
properties: 

40 

(1) "PRP001 : Product name", "PRP002: Manufac- 
turer name", "PRP003: Product code" and 
"PRP004: Standard price" which are properties of 
class T02: Office/domestic article"; 
45 (2) "PRP005: Voltage" of class T03: Digital prod- 
uct"; and 

(3) "PRP006: Standard memory capacity" and 
"PRP007: HDD capacity" of class "T04: Personal 
computer". 

50 

[0018] In this manner, class "T05: Desktop PC" can 
utilize eight properties, i.e., the above-described seven 
properties as well as "PRP008: display" which is this 
class's own property. 
55 [0019] Therefore, when class code "T05: Desktop 
PC" is selected in class tree display portion 1 01 , class 
information of "T05: Desktop PC" is displayed in the 
class information display portion 102, and the eight 
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properties are listed In the property list display portion 
103. 

[0020] Each class can have a content table which 
stores actual content data. A property set which is a 
schema of the content table is included in a set of prop- 
erties which can be utilized in a class. 
[0021 ] FIG. 3 is a view showing a structural example 
of a hierarchical database management system 1 00 ac- 
cording to the first embodiment. The hierarchical data- 
base management system 1 00 according to the first em- 
bodiment comprises a server 1 , a ciient 3 and an exter- 
nal storage device 5. The server 1 stores, e.g., hierar- 
chical information and instance data which are used to 
write product information, and presents such informa- 
tion to the user when requested. The client 3 requests 
product information for the server 1 . The external stor- 
age device 5 stores dictionary information, various kinds 
of information or content information written in a file or 
the like. 

[0022] The server 1 , the client 3 and the external stor- 
age device 5 are connected with a network 4 so that 
they can transmit/receive information to/from each oth- 
er. 

[0023] Although the external storage device 5 is con- 
nected with the server 1 through the network 4 in FIG. 

3, it may be provided in the server 1 . An input portion 
12 of the server 1 and an input portion 32 of the client 3 
are input devices such as a keyboard or a mouse. An 
output portion 13 of the server 1 and an output portion 
33 of the client 3 are display devices such as a CRT or 
a liquid crystal display. 

[0024] A control portion 1 1 of the server 1 and a con- 
trol portion 31 of the client 3 enable respective process- 
ing portions 14 to 1 8 to execute necessary processing 
in accordance with requests from the input portions 12 
and 32, respectively. The respective processing por- 
tions 1 4 to 1 8 take out information required for process- 
ing from respective storage portions 1 9 to 23 or 34 to 
36, or the external storage device 5, execute process- 
ing, and supply obtained results to the output portion 13 
or 33 or store them in the external storage device 5. 
[0025] A typical processing operation of the h ierarchi- 
cal database management system 100 will now be de- 
scribed. Upon receiving a processing request input from 
the input portion 32, the control portion 31 transmits a 
processing request to the server 1 through the network 

4. The control portion 11 of the server 1 causes one of 
the processing portions 1 4 to 1 8 to execute necessary 
processing based on the received processing request. 
The processing portions 14 to 18 read necessary data 
from, e.g., one of the storage portions 1 9 to 23, or exe- 
cute necessary processing basecron data received from 
the client 3 or the external storage device 5 through the 
network 4. A processing result may be stored in one of 
the storage portions 1 9 to 23, transmitted to and stored 
in the external storage device 5 through the network 4, 
or transmitted to the client 3. A processing result trans- 
mitted to the client 3 is displayed in the output portion 



33, or stored in one of the storage portions 34 to 36. 
[0026] A dictionary processing portion 15 acquires 
dictionary information stored in a dictionary information 
storage portion 1 9. Then, the dictionary processing por- 
5 tion 1 5 forms a class tree based on this dictionary infor- 
mation, and presents it to the user. As to presentation 
to the user, data of class tree is transmitted to the control 
portion 31 of the client 3 from the control portion 11 of 
the server 1 through the network 4, for example. The 
control portion 31 displays the received data of class 
tree in the output portion 33. FIG. 4 is a view showing a 
display example of a class tree presented to the user. 
In a class tree display portion 41 depicted in FIG. 4, 
when a hierarchical classification (class) is selected by 
the user through the input portion 12 or the like, the dic- 
tionary processing portion 15 displays information of the 
class such as a definition or a note as the class infor- 
mation display portion 102 shown in FIG. 1 in accord- 
ance with a type of this class (a regular class, a synon- 
ymous class and others), and displays a list of properties 
which are defined in this class and inherited from a super 
class as the property list display portion 1 03 depicted in 
FIG. 1. 

[0027] The type of class is stored in the dictionary in- 
formation storage portion 19. FIG. 5 is a view showing 
an example of a storage format of types of classes 
stored in the dictionary information storage portion 19. 
As shown in FIG. 5, classes, related classes and rela- 
tionships between classes and related classes are as- 
sociated with each other and stored. In FIG. 5, each 
class or each related class comprises class code and 
the class name. For example, in regard to data of a dic- 
tionary information class at the top in FIG. 5, "Z03" is 
class code, and T company personal computer" is the 
class name. The dictionary processing portion 1 5 forms 
a class tree based on this dictionary information. 
[0028] A description will be given hereinafter while 
setting the example of FIG. 5 forth as a premise unless 
otherwise specified. In FIG. 5, a usual class (which will 
be referred to as "regular class" hereinafter) is designat- 
ed as "sub-class" of a given class. For example, in the 
third dictionary information from the top in FIG. 5, class 
"Z03: T company personal computer" means a sub- 
class of class "Z02: Personal computer purchase cate- 
gory". Further, in the first dictionary information from the 
top in FIG. 5, class "Z03: T company personal computer" 
means a synonymous class of class T04: Personal 
computer" which exists in another class tree. The "syn- 
onymous class" is a classification and an expression of 
a class which is commonly used for users who belong 
to a given community or organization, e.g., a product 
classification in a sales department (with respect to a 
product classification in a manufacture category). The 
synonymous class is a concept which is in contradistinc- 
tion from the regular class. That is, a classification 
(class) which makes reference is the synonymous class, 
and a classification (class) which is referred to by the 
synonymous class is the regular class. A relationship 
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with a related class functions as identification informa- 
tion which identifies the regular class and the synony- 
mous class. Furthermore, as can be understood from 
FIG. 5, the synonymous class is written as an entity 
which is independent from the regular class. 
[0029] The dictionary processing portion 15 displays 
class tree in which class °Z03° is a sub-class of class 
"Z02" and also displays symbol "SYN" which is indica- 
tive of a synonymous class in class tree based on syn- 
onym information indicative of a synonymous class, as 
shown in FIG. 4. As a result, a fact that class "Z03" is a 
synonymous class is explicitly presented to the user, the 
user can easily recognize that this is a class different 
from the regular class. 

[0030] A dictionary input/output processing portion 1 4 
reads a dictionary file having, e.g., Part21 format exist- 
ing in the external storage device 5, interprets it, and 
stores it in the dictionary information storage portion 1 9. 
The format of the dictionary is usually Part21 , but any 
other format may be used. When synonymous setting 
information or the like is written in another file, the 
above-described file is read together with or before/after 
this file, and stored in the dictionary information storage 
portion 1 9. The dictionary information stored in the dic- 
tionary information storage portion 19 is presented to 
the output portion 1 3 or 33 or output to the external stor- 
age device 5 in the form of, e.g., a file having Part21 
format or any other format. 

[0031] A class edit processing portion 16 edits the 
synonymous information separately input thereto by us- 
ing the GUI, and stores it in the dictionary information 
storage portion 1 9. 

[0032] A content table view setting processing portion 
1 7 acquires a structure of each content table from a con- 
tent table storage portion 23, and presents to the user 
a GUI which is used to set conditions for search or dis- 
play of instance data. Further, the content table view set- 
ting processing portion 1 7 stores a content table in a 
content table view information storage portion 21 in ac- 
cordance with input by the user. The content table view 
setting portion 1 7 reads conditions from a file stored in, 
e.g., the external storage device 5 rather than the GUI, 
and executes the same processing. 
[0033] An association processing portion 1 8 presents 
to the user a GUI which is used to associate a class, 
each content table view information and a content table 
with each other, executes association in accordance 
with input from the user which is concretely input of an 
association command, and stores association informa- 
tion in an association information storage portion 32. 
The association processing portion 1 8 reads conditions 
from a file stored in, e.g., the exte m a r ato r ayb 1 device ir 
rather than the GUI, and executes the same processing. 
[0034] A MY FAVORITES information storage portion 
20 stores in accordance with the user or a group a MY 
FAVORITES class which is substantially the same as a 
synonymous class but can be defined in accordance 
with the user or a group. Since the MY FAVORITES 



class can be freely defined in accordance with the user 
or a group, it is not processed as dictionary information 
like the synonymous class. 

[0035] The MY FAVORITES class can be set by using 

5 the GUI which is the same as that used in setting the 
synonymous class in the class edit processing portion 
16. In this case, however, since the MY FAVORITES 
class is not treated as dictionary information as different 
from the synonymous class, it is stored in the MY FA- 

10 VORITES information storage portion 20 ratherthanthe 
dictionary information storage portion 19. 
[0036] In the example shown in FIG. 3, although the 
dictionary processing portion 15, the class edit process- 
ing portion 1 6, the content table view setting processing 

*5 portion 1 7 and the association processing portion 1 8 are 
constituent elements of the server 1 , they may also ac- 
cess to a database existing in the server 1 and execute 
processing in the client 3 based on the obtained data as 
constituent elements of the client 3. In this case, all or 

20 any of the respective processing portions 15 to 18 are 
provided in the client 3. 

[0037] FIG . 4 is a display example of a class tree used 
when a purchasing department of Z company purchas- 
es materials. Class trees of both the T company and the 

25 x company are shown. The purchasing department of 
the Z company selects a product classification (class) 
from the product class trees of the T company and the 
X company. There is a Personal computer purchasing 
department in the purchasing department of the T com- 
ae pany. Since this Personal computer purchasing depart- 
ment does not perform purchasing acts other than Per- 
sonal computer purchasing, it is troublesome for a per- 
son in charge in this Personal computer purchasing de- 
partment to trace class tree and display "Personal com- 

35 puter" each time. Therefore, when the dictionary infor- 
mation processing portion 1 5 registers a class common- 
ly utilized in the Personal computer purchasing depart- 
ment as a synonymous class for the Personal computer 
purchasing department like a bookmark, the Personal 

40 computer purchasing department can easily jump to a 
necessary product classification (class). 
[0038] In the example shown in FIG. 4, the dictionary 
information processing portion 15 creates a class tree 
for the purchasing department as a dictionary, creates 

45 a Personal computer purchasing department of product 
classification Z02 under the purchasing department of 
product classification Z01 , and sets Z03 and Z04 under 
product classification Z02 as synonymous classes of 
T04 and X03, respectively. 

so [0039] FIG. 6 shows an example where synonymous 
classes are displayed in another window. As shown in 
RG. ft, the dictionary information processing portion 15 
displays the synonymous classes in a synonymous 
class display portion 62 as a window different from class 

55 tree display portion 61 . This synonymous class display 
portion 62 may be displayed when the user selects a 
button 63, for example. 

[0040] As described above, in this embodiment, when 



6 



11 



EP1583 002 A2 



12 



it is confirmed that substantial classifications are the 
same between a plurality of different classification sys- 
tems by any method, an actual content is set in one of 
these classes, and any other classes are processed as 
"synonymous classes" which have different codes but 
the same meaning. As a result, it is possible to avoid 
double registration having the same content with differ- 
ent names or classification codes. 
[0041] Effects and advantages of this embodiment 
will now be described taking ISO 13584 Parts Library 
("PLIB") standards. In the PLIB standards, there is no 
concept of synonymous classes. Based on the PLIB 
standards, sources of concepts throughout the world 
can be uniquely specified by using codes of communi- 
ties (Supplier_BSU) which issue classifications uniquely 
determined according to the ISO 6523 International 
Code Designator (ICD) standards, codes of classes 
(Class_BSU) issued by such communities, and codes 
allocated to properties (Property_BSU) defined in ac- 
cordance with each class and inherited to sub-classes. 
The same concept is not expressed by using two differ- 
ent codes and there is no such a need as long as sets 
of Supplier_BSU and Class_BSU and sets of 
Supplier_BSU, Class-BSU and Property_BSU are 
used. 

[0042] I n reality, however, there are community stand- 
ards which do not accurately comply with the PLIB 
standards. Further, it is often the case that classifica- 
tions in companies differ depending on a difference or 
convenience in production or sales organization sys- 
tems in companies. In order to avoid a confusion based 
on such a difference in classification, names or identifi- 
cation codes different from the classification of other 
companies may be intentionally allocated in some cas- 
es. Therefore, uniform classifications using the PLIB 
standards only cannot be expected. 
[0043] Thus, in this embodiment, a classification code 
system which does not accurately comply with the PLIB 
standards is associated with the ISO 13584 standards. 
Furthermore, when it can be judged that the classifica- 
tion in this classification code system is substantially the 
same as a class classified based on the ISO 13584 
standards by definition, the classification class in the 
GUI is processed as a different class mark having a 
code different from the PLIB standards. Content (in- 
stance) is generated as the same classification in the 
dictionary information storage portion 1 9. Therefore, the 
problem of double registration of the content can be 
avoided. Moreover, it is possible to avoid a problem that 
search is possiblefrom one classification but it is impos- 
sible from the other classification even though these 
classifications have the same concept. 
[0044] The thus created synonymous class which is 
classification information as a header is written by using 
CASE_OF which is defined based on ISO 13584-Part42 
standards. Alternatively, the synonymous class can be 
written as dictionary information complying with the in- 
ternational standards in a format specialized while main- 



taining the upward compatibility with ISO 13584-Part42 
(standards, Vol. No. 42) standards which define a dic- 
tionary format. 

[0045] As a result, in any other database system or 
5 library management system (LMS), the synonymous 
class can be realized by transferring the same classifi- 
cations. The synonymous class is a classification and 
an expression of a class which is commonly used with 
respect to users who belong to a given community or 
10 organization. Therefore, it is very important to output a 
file as a different classification system and read this file 
to any other database or LMS so that the same classi- 
fication can be utilized. 

[0046] Collateral information which is required to write 
the synonymous class as an entity independent from the 
regular class is associated with the synonymous class, 
and the synonymous class can be generated by reading 
identification information of the synonymous class and 
the regular class written in the collateral information. 

20 [0047] As described above, according to this embod- 
iment, class code which Is independent from class code 
allocated to the regular class is allocated together with 
class code of the regular class, the identification infor- 
mation which is used to identify the synonymous class 

25 from the regular class is associated. Therefore, the syn- 
onymous class forming a hierarchical structure inde- 
pendently from the regular class is displayed in such a 
manner that the synonymous class can be distinguished 
from the regular class by reading the identif ication infor- 

30 mation. As a result, information associated with a given 
classification can be referred to and utilized from any 
other standard classification. Here, the collateral infor- 
mation is, e.g., (i) definition information of a given clas- 
sification, (ii) definition or data type information of a 

35 property which belongs to a given classification, (iii) data 
values of all or part of properties of instance data which 
belongs to a given classification or a content table which 
is a set of instance data. With this identification informa- 
tion, the synonymous class can be distinguished from 

40 the regular class in an internal expression in the com- 
puter. 

[0048] As a result, a given group of users can trace a 
classification structure in accordance with a dictionary 
which conforms to customs or rules in the group. Fur- 

45 ther, users can identify and select classifications by us- 
ing familiar classification symbols or standard names. 
[0049] (i) In a hierarchical structure of a database 
which performs output by the system, a synonymous 
class is written as an entity different from a regular class. 

so This is also applied to a description of a hierarchical 
structure in input/output files. That is, a synonymous 
class can have a name, a code, a defined community of 
the synonymous class, or a utilized organization and 
any other collateral information independently of a reg- 

55 ular class, (ii) A synonymous class can be automatically 
generated in the system by the description of the syn- 
onymous class written in a file input to the system. Fur- 
ther, (iii) a file used in (i) and (ii) is read to any other 
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database so that the same synonymous class can be 
automatically generated in this database. 

(Second Embodiment) 

5 

[0050] FIGS. 7 to 10 are views illustrating a second 
embodiment of the present invention. It is assumed that 
class "Z03: T company personal computer" and class 
T04: Personal computer" have a relationship between 
a synonymous class and its source class. 10 
[0051] FIG. 7 is a view showing a display example of 
source class. When the user performs an operation for 
putting a mouse cursor on a synonymous class in class 
tree display portion 71 in FIG. 7 by using the input por- 
tion 12, class code or the like of the source class is dis- 15 
played by using a balloon 72 or the like. In the example 
of FIG. 7, the balloon 72 shows the class name and class 
code. When a synonymous class is selected by the input 
portion 1 2 in this manner, the dictionary processing por- 
tion 1 5 or the class edit processing portion 1 6 displays 20 
class code of a regular class as the source class togeth- 
er with class code of the synonymous class. 
[0052] FIG. 8 is a view showing a display example of 
a synonymous class. When a cursor is placed on source 
class in class tree display portion 81 shown in FIG. 8, 25 
class code or the like of the synonymous class is dis- 
played by using a balloon 82 or the like. In the example 
shown in FIG. 8, the balloon 82 shows the class name 
and dass code. When a regular class is selected by the 
input portion 1 2 in this manner, the dictionary processing 30 
portion 15 or the class edit processing portion 16 dis- 
plays class code of the synonymous class together with 
class code of the regular class which is source class. 
[0053] Moreover, when there is a special display re- 
quest, there can be adopted a method which displays a 35 
code of source class as a sub-class of each synony- 
mous class in class tree or a method which displays a 
synonymous class as a sub-class of source class. 
[0054] FIG. 9 is a view showing a screen example 
where source class is displayed. In a class tree display *o 
portion 91 shown in FIG. 9, when, e.g., a button 33 is 
selected, the dictionary information processing portion 
15 displays source class T04: Personal computer" like 
a sub-class of a synonymous class "Z03: T company 
personal computer". 45 
[0055] FIG. 10 is a view showing an example of a 
screen which displays a synonymous class. When, e.g., 
a button 34 is selected in a class tree display portion 96 
in FIG. 1 0, the dictionary information processing portion 
15 displays a synonymous class like a sub-class of so 
source class T04: T company personal computer". The 
source class and the synonymous class dlsp fayed ffRe 
a sub-class clearly indicate that they are source class 
in a synonymous class or a synonymous class in source 
class, respectively, by differentiating display from that of 55 
a regular sub-class, e.g., by using italic type or display- 
ing a mark as well. 

[0056] The respective display methods in the synon- 



ymous class and its source class are not restricted to 
those described above, and there can be considered 
various methods such as a method of displaying classes 
in another screen by right click or the like in place of 
displaying a balloon, a method or displaying classes in 
the class information display area 1 02 in FIG. 1 and oth- 
ers. 

[0057] As described above, according to this embod- 
iment, class code of a regular class can be displayed as 
a reference target code of a synonymous class, and a 
code of a synonymous class can be displayed as a syn- 
onymous class code (a synonymous classification 
code). 

(Third Embodiment) 

[0058] This embodiment relates to an embodiment in 
which a synonymous class is written by utilizing CaseOf 
in a dictionary which can be defined based on the ISO 
13584 standards. 

[0059] A dictionary which can be defined based on the 
ISO 13584 standards is a simple tree. That is, classes 
form a simple inheritance relationship in which they 
have one superclass only. However, there is a concept 
of CaseOf which can import a plurality of properties 
which can be used by each of a plurality of classes from 
the plurality of classes. A partial inheritance is enabled 
between classes by utilizing CaseOf. 
[0060] The dictionary processing portion 15 or the 
class edit processing portion 16 generates a class tree 
by making reference to CaseOf. 
[0061] FIG. 11 is a view showing an example of a 
class tree according to this embodiment. In FIG. 11, 
class 1 , class 2 and class 3 are simple trees and they 
are coupled with each other in a hierarchical relationship 
of a simple inheritance. Class 11 and class 12 are also 
simple trees, coupled with each other in a hierarchical 
relationship, and inherit properties of super classes. 
[0062] In FIG. 11, the properties with a dot-printed 
background are indicative of properties inherited from 
super classes. That is, dass 2 has a property 1 and a 
property 2 inherited from class 1. In this manner, this 
embodiment forms a multi inheritance relationship in 
which a sub-class inherits properties from a plurality of 
super classes. 

[0063] Class 2 is defined by a CaseOf class, and im- 
ports a property 1 1 from class 1 1 . By importing the prop- 
erty, class 2 can then utilize property 11 as its own prop- 
erty. 

[0064] It should be noted that a class which is referred 
to based on CaseOf (a regular class) will be referred to 
as" "reference class" and an imported property will be 
referred to as an "imported property" in the following de- 
scription of this embodiment In the example of FIG. 11 , 
"reference class" is class 11 , and "imported property" is 
property 11. 

[0065] In this embodiment, the expression of a syn- 
onymous class utilizing a reference relationship be- 
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tween classes is possible by expanding the concept of 
CaseOf. 

[0066] FIG. 1 2 is a view showing a description exam- 
pie of dictionary information based on the ISO 13584 
standards utilizing a Part21 file format. Data is written 
in Part21 file based on a schema using EXPRESS de- 
fined based on the ISO 13584 standards. The schema 
has an entity as a basic unit constituting the schema and 
its attribute. Each entity has a name. 
[0067] I n the description following "DATA;" on the mid- 
dle stage in FIG. 12, a number prefixed by a hash mark 
at the top of each line is a number allocated to each 
entity, and the entity can be thereby identified. An entity 
name follows the sign of equality. Attributes are aligned 
in a comma separated value format between parenthe- 
ses after each entity name. A number prefixed by a hash 
mark which is written in the attribute means that refer- 
ence is made to an entity defined in another line. 
[0068] FIG. 1 3 is a view selectively showing a part de- 
scribing class information in Part21 file. In FIG. 13, in- 
formation concerning class "Z02: Personal computer 
purchasing department" is written in lines from #1 026 to 
#1025 denoted by reference numeral 131. Information 
concerning class "Z03: T company personal computer" 
is written in lines from #1 01 9 to #1 01 8 denoted by ref- 
erence numeral 132. Information concerning class "Z04: 
X company Personal computer* is written in lines from 
#1012 to #1011 designated by reference numeral 133. 
[0069] An entity representing a OaseOf class is de- 
fined as a sub-entity of an entity expressing a regular 
class. The first to fifteenth entities representing CaseOf 
classes are attributes indicative of information of class- 
es inherited from entities representing classes. The six- 
teenth and subsequent attributes are indicative of infor- 
mation of CaseOf. 

[0070] That is, taking a line #1020 denoted by refer- 
ence numeral 132 as an example, the first attribute 
"#1019" to the fifteenth attribute "$" are indicative of 
class information of °Z03: T company personal compu- 
ter", and the sixteenth attribute "*" and subsequent at- 
tributes are indicative of information of CaseOf. Each 
attribute is indicative of information as follows: 
[0071] The first attribute is indicative of a code which 
uniquely identifies a class, i.e., "Class BSU"; 

the fourth attribute is indicative of "Preferred 
name"; 

the eighth attribute is indicative of "Remark"; 

the ninth attribute is indicative of "Super class"; 

the twenty-first attribute is indicative of an identi- 
fier of a class which is referred to in CaseOf, i.e., "Ref- 
erence class BSU"; and 

the twenty-second attribute- is frrdteattre of prop- 
erties imported from the class which is referred to in Ca- 
seOf, i.e., a set of "imported properties". 
[0072] Therefore, specifically, information which can 
be read from #1020 designated by reference numeral 
132 and lines which are referred to by this line are as 
follows. 



[0073] As apparent from the entity name, class type 
is a CaseOf class (component_class__case_of). "Class 
BSU" is Z03, "Standard name" is T company personal 
computer, "Remark" is $SYNONYM, "Super class" is 
5 Z02, and "Reference class" is T04. "Imported property" 
is indicative of null (no existence). 
[0074] Even if the class information in Part21 file 
shown in FIG. 13 is read by the regular database man- 
agement system based on the ISO 13584 standards, 
class Z03 is recognized as a regular CaseOf class hav- 
ing class T04 as a reference class. Further, ^SYNO- 
NYM" written in the attribute "Remark" does not have 
information other than a (human readable) character 
string which can be read by the user. 
[0075] In this embodiment, a predetermined special 
character string "$SYNONYM" is written in "Remark" 
which is an attribute of the CaseOf entities. As a result, 
when information is read by the hierarchical database 
management system 100 according to this embodi- 
ment, a class of this character string is recognized as a 
synonymous class while its reference class is recog- 
nized as source class of the synonymous class, and the 
classes are stored in the dictionary information storage 
portion 1 9 so that the class can be processed as the 
synonymous class in the hierarchical database man- 
agement system 100. That is, "$SYNONYM" in the re- 
mark column is recognized as identification information 
which identifies the synonymous class from other class- 
es. 

[0076] Moreover, since information indicative of the 
synonymous class is usually added by utilizing one of 
attributes of CaseOf entities, the compatibility of the reg- 
ular Part21 file can be guaranteed. 
[0077] As described above, in this embodiment, the 
synonymous class is written by using a class in a clas- 
sification system different from a classification system 
of the hierarchical database and an entity which imports 
a property, the hierarchical database forms a simple in- 
heritance structure in which a sub-class comprises only 
one super class, and the class edit processing portion 
16 can process this structure as a mufti inheritance re- 
lationship in which a sub-class comprises a plurality of 
super classes based on the hierarchical database. 



[0078] This embodiment relates to an embodiment 
which writes a synonymous class by a technique differ- 
ent from that of the third embodiment 

so [0079] In this embodiment, the synonymous class is 
written as a regular class rather than a CaseOf class. 
Additionally, a synonymous class is written by adding to 
the attribute "Remark" 1 ) information indicative of a syn- 
onymous class and 2) information which identifies 

55 source class. 

[0080] FIG. 14 is a view selectively showing a part in 
which the class information is written in a Part21 file ac- 
cording to this embodiment. Lines denoted by reference 



45 (Fourth Embodiment) 



15 



20 



25 



30 



35 



9 



17 



EP 1 583 002 A2 



18 



numerals 141 , 142 and 143 correspond to the descrip- 
tion of lines designated by reference numerals 131 , 1 32 
and 133 in FIG. 13 of the third embodiment, respectively. 
[0081] That is, information concerning class "Z03: T 
company personal computer" is written in lines of #1019 5 
to #1018 designated by reference numeral 142. Infor- 
mation concerning class "Z04: X company Personal 
computer" is written in lines of #1012 to #1011 denoted 
by reference numeral 1403. 

[0082] Taking a line #1 020 denoted by reference nu- 
meral 142 as an example, class type is a regular class 
(Component_class) based on an entity name, "Class 
BSU n is Z03, "Standard name" is T company personal 
computer, "Remark" is $SYNONYM-14Q/T_Company//. 
T04-001 , "Super class" is Z02, and "Import property" is 
null (non-existent). Like the example shown in FIG. 13, 
"$ SYNONYM-140/T_Company//.T04-001 " in "Remark" 
does not have a meaning other than a character string 
even if this is read by the regular database management 
system. 

[0083] Conversely, in case of the hierarchical data- 
base management system according to this embodi- 
ment, for example, first eight characters in the attribute 
remark of class information written as a regular class 
related with $SYNONYM, the dictionary information 
processing portion 1 5 determines this class as a synon- 
ymous class, recognizes a character string from the 
ninth hyphen sign as an identifier of source class of the 
synonymous class, and stores the class in the dictionary 
information storage portion 19. As a result, this class 
can be processed in the hierarchical database manage- 
ment system 1 00 as the synonymous class. 
[0084] Further, since information indicative of the syn- 
onymous class by utilizing one of attributes of CaseOf 
entities is usually added, the compatibility can be guar- 
anteed as the regular Part21 file. 
[0085] As described above, in this embodiment, a 
synonymous class is written by using a class of a clas- 
sification system different from a classification system 
of the hierarchical database and an entity which imports 
properties, the hierarchical database forms a simple in- 
heritance structure in which a sub-class comprises only 
one super class, and the class edit processing portion 
16 can processes this structure as a multi inheritance 
relationship in which a sub-class comprises a plurality 
of super classes based on the hierarchical database. 
[0086] For example, in case of input/output utilizing a 
file defined in the ISOl 0303-21 (a so-called "STEP file"), 
a class having a synonymous class code is written by 
utilizing a structure for import of classes or properties 
from any other classification system defined in the ISO 
13584-24, i.e., "CASEJDF" tfrem_class_case_j>f, 
component_class_case_of, material_class_case_of 
and others) entities. Further, a comment or an annota- 
tion incidental to CASE_OF is used. As a result, a fact 
that this description is actually a synonymous class is 
clearly written, and the compatibility with the IS0 1 3584 
standards can be maintained. Furthermore, the simple 



inheritance in which a class demanded by the ISO 
1 3584 standards has only one super class can be main- 
tained in an input/output file. Moreover, when data is 
once read, multi inheritance or multi classification is sub- 
stantially enabled. 

(Fifth Embodiment) 

[0087] This embodiment relates to an embodiment of 
the description of a synonymous class utilizing a file for- 
mat other than Part21 file format. 
[0088] In the ISO 13584 standards, dictionary infor- 
mation is usually transmitted/received in the form of a 
Part21 file, but there is, e.g., a table-like dictionary de- 
scription method using an XML format (Simplib), a class 
inquiry language (CQL) or CSV other than Part21 file. 
These description formats can likewise simplify and 
write entities and attributes in Part21 file, and hence the 
same processing as that of Part21 file according to the 
third embodiment or the fourth embodiment can be re- 
alized. 

[0089] FIGS. 1 5 to 1 7 are views showing a description 
example of synonymous classes according to this em- 
bodiment. 

[0090] FIG. 1 5 is a view showing examples of a table- 
like dictionary description mode using CSV or the like. 
As shown in FIG. 15, an attribute of an entity indicative 
of class information is determined as an item, informa- 
tion of one class is represented by one line of a CSV 
file. I n case of FIG. 1 5, an entity name is written in "Class 
type". A special character string indicative of a synony- 
mous class, e.g., SYNONYM_COM PON ENT_CLAASS 
is written in "Class type". As a result, the hierarchical 
database system 1 00 can process a synonymous class 
which is different from any other regular class. Moreo- 
ver, although a reference class of a CaseOf class is usu- 
ally written in an item "Reference target class", source 
class of a synonymous class can be written by utilizing 
"Class type". 

[0091] Likewise, the description method can be real- 
ized by writing synonym information in another item, e. 
g., "Remark" as mentioned above. 
[0092] FIG. 16 is a view showing an example of per- 
forming a class definition in the class inquiry language 
(CQL). In FIG. 1 6, an example of performing a definition 
of a regular class is shown, and a "Remark" attribute 
includes synonym information (indication of a synony- 
mous class, and information of source class). 
[0093] FIG. 1 7 is a view showing another example of 
performing a class definition in the class inquiry lan- 
guage (CQL). In FIG. 17, an example of performing a 
definition of a CaseOf class is shown, a "Remark" at- 
tribute includes synonym information (indication of a 
synonymous class) and a is_case_of attribute includes 
source class information. 

[0094] As described above, according to this embod- 
iment, in cases where a synonymous class does not 
have an instance, when a file in which identification in- 
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formation indicative of a synonymous class is written is 
read, the class edit processing portion 16 can detect a 
synonymous class based on this identification informa- 
tion. 

[0095] For example, indication of a synonymous class 5 
can be expressed by giving an additional attribute to a 
class as a reference target or additional information 
such as a special comment utilizing a column of Notes, 
remark and the like. As a result, indication of a synony- 
mous class can be detected by inputting/outputting 10 
class To/from the data base in such a manner that the 
class can be distinguished from a regular class. 

(Sixth Embodiment) 

15 

[0096] This embodiment is an embodiment concern- 
ing the description of a synonymous class using EX- 
PRESS. 

[0097] FIG. 18 is a view showing an example of the 
description of a synonymous class using EXPRESS in 20 
which an entity defined in the ISO 13584 standards is 
extended. Additionally, FIG. 19 is a view showing a de- 
scription example of EXPRESS-G including an associ- 
ative entity. In the example shown in FIG. 19, synony- 
mous classes (which are synonym_item_class 189, 25 
synonym_component_class 190, synonym_material_ 
class 191 and synonym Jeature_class 192, respective- 
ly) are extended and defined as low-order entities of Ca- 
seOf class entities (which are item_class_case_of 185, 
com po nent_class_case_of 186, material_class_ 30 
case_of 1 87 and feature_class_case_of 1 88, respec- 
tively) which are defined as low-order entities of regular 
class entities (which are ltem_class 181, component, 
class 182, materiaLclass 183 and feature__class 184, 
respectively). 35 
[0098] FIG. 20 shows an example where information 
is written in a Part21 file by utilizing extension entities 
depicted in FIG. 19. Reference numeral 201 denotes the 
description of definition information of class "Z02: Per- 
sonal computer purchasing department"; reference nu- *o 
meral 202, the description of definition information of 
class "ZQ3: T company personal computer"; and refer- 
ence numeral 203, the description of definition informa- 
tion of class "Z04: X company Personal computer". 
[0099] As shown in FIG. 1 9 or20, as low-order entities 45 
of the CaseOf classes, entities each representing a syn- 
onymous class are extended without adding attributes. 
That is, the synonymous class is defined as a sub-class 
of a regular class. As a result, information can be trans- 
mitted to a regular database management system com- so 
plying with the ISO 13584 standards which do no inter- 
pret the synonymous class by just converting a synon- 
ymous name into a super entity. 
[0100] Furthermore, in this example, although the en- 
tity is extended as a low-order entity of the CaseOf class, 55 
any other EXPRESS extension may be used. For exam- 
ple, the entity may be directly defined as a low-order 
entity of a regular class. 



[0101] As described above, according to this embod- 
iment, when a synonymous class does not have an in- 
stance and the synonymous class is defied in a hierar- 
chical database as a sub-class of an entity defined in a 
classification system of the hierarchical database, the 
class edit processing portion 1 6 can detect indication of 
the synonymous class based on the sub-class. 

(Seventh Embodiment) 

[01 02] This embodiment relates to an embodiment in 
which synonymous information is given to another file. 
[0103] FIGS. 21 to 24 are views illustrating the de- 
scription of synonymous information according to this 
embodiment. 

[0104] FIGS. 21 and 22 show a first description ex- 
ample, and FIGS. 23 and 24 show a second description 
example. 

[01 05] FIGS. 21 and 22 form a pair. FIG. 21 shows an 
example of a Part21 file in which a synonymous class 
is written as a usual class, i.e., a regular class. Refer- 
ence numeral 211 denotes definition information of a 
class having class code Z02; reference numeral 212, 
definition information of a class having class code Z03; 
and reference numeral 213, definition information of a 
class having class code Z04. FIG. 22 is a view showing 
an example of a synonymous information file in which 
information to be used to recognize as a synonymous 
class a synonymous class defined as a regular class in 
FIG. 21 is described. An identifier (class BSU) of classes 
(classes Z03 and Z04 in FIG. 22) as synonymous class- 
es and an identifier (class BSU) of classes (classes T04 
and X03 in FIG. 22) as source classes are written in the 
synonymous information file shown in FIG. 22. At the 
time of reading Part21 file shown in FIG. 21 to the hier- 
archical database management system 100, when the 
dictionary input/output processing portion 1 4 reads the 
synonymous information file depicted in FIG. 22 as an 
auxiliary file together with Part21 file or read the synon- 
ymous information file before/after reading Part21 file, 
the hierarchical database management system 1 00 reg- 
isters the classes having class codes of Z03 and Z04 as 
synonymous classes. 

[0106] FIGS. 23 and 24 form a pair. FIG. 23 is a view 
showing an example of Part21 file in which a synony- 
mous class is written as a regular CaseOf class. FIG. 
24 is a view showing an example of synonymous infor- 
mation file in which information which is used to recog- 
nize as a synonymous class the synonymous class de- 
fined as the regular CaseOf class is written. A class 
identifier (class BSU) of classes (classes Z03 and Z04 
in FIG. 24) as synonymous classes is written in the syn- 
onymous information file depicted in FIG. 24. At the time 
of reading Part21 file shown in FIG. 23 to the hierarchical 
database management system 1 00, when the dictionary 
input/output processing portion 14 reads the synony- 
mous information file in FIG. 24 as an auxiliary file to- 
gether with Part21 file or reads the synonymous infor- 
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mation file before/after reading Part21 file, the hierarchi- 
cal database management system 100 registers class- 
es Z03 and Z04 as synonymous classes. 
[01 07] Therefore, by giving the synonymous class in- 
formation in a file different from Part21 file, the regular $ 
database management system based on the IS0 1 3584 
standards can process Part21 file without including the 
synonymous information. 

[01 08] As described above, according to this embod- 
iment, when the synonymous class does not have an 10 
instance and the synonymous class is written by using 
a first file or database according to a first classification 
system of the hierarchical database, a second file or da- 
tabase according to a second classification system dif- 
ferent from the first classification system and a third file is 
or database in which synonymous reference information 
of the first classification system and the second classi- 
fication system is written, the class edit processing por- 
tion 16 can detect indication of the synonymous class 
based on the synonymous reference information in the 20 
third file or database. 

(Eighth Embodiment) 

[01 09] This embodiment relates to an embodiment of 25 
display of a synonymous class. 
[0110] FIG. 25 is a view showing a display example 
of a synonymous class according to this embodiment. 
This display example comprises a class tree display por- 
tion 251 , a class information display area 252 and a 30 
property list display area 253. 

[01 1 1 ] FIG. 26 is a view showing a flowchart of a syn- 
onymous class display operation by the class edit 
processing portion 1 6. 

[01 12] As shown in FIG. 25, when the user selects a 35 
class by operating the input portion 12, e.g., by clicking 
a mouse in class tree display portion 251 (step 261), the 
class edit processing portion 16 judges whether this 
class is a regular class or a synonymous class (step 
S262). In case of the regular class, the class edit *0 
processing portion 16 displays class information or a 
property list of the selected class (step S268). If the se- 
lected class is a synonymous class, the class edit 
processing portion 1 6 adds the selected class in a ref- 
erence class history list (step S263). Then, a reference 
target class of the class written in the reference class 
history list is specified by, e.g., making reference to the 
dictionary information storage portion 1 9 by the class 
edit processing portion 16 (step S264). Further, the 
class edit processing portion 1 6 judges whether the ref- so 
erence target class Is a synonymous class (step S265). 
If it is not a synonymous class, the class included in the 
reference class history list and the reference target class 
are selected (step S269), information of these selected 
classes is displayed, and a property list of the selected 55 
classes is displayed in the property list display portion 
(step S268). 

[0113] If the reference target dass is determined as 



a synonymous class at the step S265, the class edit 
processing portion 1 6 judges whether the reference tar- 
get class has been already included in the reference 
class history list (step S266). If the reference target dass 
is not induded in the reference dass history list, the con- 
trol returns to processing which adds the reference tar- 
get class to the reference class history list (step S263). 
If the reference target class is included in the reference 
class history dass, the class edit processing portion 1 6 
selects all classes included in the reference dass history 
list, and displays an error message indicating that the 
reference forms a loop (step S267). 
[0114] By selecting the source class as well and dis- 
playing dass information or a property list of the source 
class in this manner, the synonymous dass serves like 
a bookmark, and the user can readily access the source 
class. 

[0115] In the example shown in FIG. 25, when "203: 
T company personal computer* is selected, T04: Per- 
sonal computer" is also selected at the same time, and 
class information of T04: Personal computer" is dis- 
played in the dass information display area 252 and the 
property list of T04 is displayed in the property list dis- 
play area 253 by the class edit processing portion 16. 
This is the same as a screen in which T04 is selected 
except that the synonymous dass Z03 is selected. 
[0116] Furthermore, in cases where reference from 
the synonymous class to the source dass in class tree 
display portion 251 takes such a conformation as shown 
in FIG. 9, when "Z03: Personal computer" is selected, 
the class edit processing portion 1 6 displays class infor- 
mation and a property list of class Z03. Another stage 
may be provided so that the class edit processing por- 
tion 16 can display class information and a property list 
of source class T04: T company personal computer" 
which is an entity when "T04: T company personal com- 
puter" (italic type) virtually displayed below class Z03 is 
selected. 

[01 1 7] As described above, according to this embod- 
iment, when the user selects a synonymous dass dis- 
played in the screen by using the input portion twelfth 
class edit processing portion 1 6 detects selection of this 
synonymous class so that a regular class which is re- 
ferred to by the synonymous dass can be read and dis- 
played in the screen. 

(Ninth Embodiment) 

[01 18] This embodiment relates to an embodiment of 
automatic conversion of a search query. 
[01 19] FIG. 27 is a view illustrating an automatic con- 
version function of this embodiment. 
[01 20] In this embodiment, a synonymous class does 
not have instance data. Even if a synonymous dass has 
such data, the data is just supplementary information of 
instance data existing in source class, and it does not 
have any meaning. 

[0121] It is assumed that a class tree is formed as 
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shown in FIG. 27. That is, it is assumed that class D Z03: 
T company personal computer" is a synonymous class 
of class T04: Personal computer". Moreover, it is as- 
sumed that a content table Tabled as a set of instance 
data exists in sub-class "T05: Desktop PC" of source 5 
class T04: Personal computer", and content table 
Table02 exists in sub-class "T06: notebook PC". 
[0122] It is assumed that the following (1) content 
search query is requested to T04 which is a regular 
class, for example. to 

Select PRP001 , PRP003 from T04* where PRP006 = 

512; (1) /5 

[0123] In response to this search query (1), the class 
edit processing portion 1 6 displays a Product name and 
Product code as properties of instance data whose 
memory is 51 2 instance data existing in class T04 and 20 
subsequent classes (T04, T05 and T06 in this example). 
That is, instance data of Equium 01 and Equium 03 in 
Tabled and Dyna 001 in Table02 is displayed as a re- 
sult. 

[01 24] Even if display of the instance data is executed 25 
with respect to the synonymous class having class code 
Z03 , the class edit processing portion 1 6 outputs a result 
obtained by performing display with respect to the 
source class having class code T04 rather than the in- 
stance data existing in Z03 and subsequent classes. 30 
That is, the class edit processing portion 16 reads that 
the class having class code Z03 is a synonymous class 
and its source class has class code T04 from the written 
information shown in FIG. 5 in response to the following 
search query (2), and executes the search query (1 ) in 35 
which the class having class code Z03 is converted into 
the class having class code Z04. 

Select PRP001 , PRP003 from Z03* where PRP006 = ^ 
512; (2) 

[01 25] Although the above-described example corre- 
sponds to processing when a synonymous class is se- 45 
lected as a search target of instance data, processing 
is likewise executed with respect to source class of a 
synonymous class when another processing request is 
generated with respect to the synonymous class. 
[01 26] As described above, according to this embod- so 
iment, when the class edit processing portion 1 6 detects 
that the target of an operation using the i npu t portion 12 
or of data processing is a synonymous class, processing 
of a regular class wh ich is referred to by the synonymous 
class is executed. As a result, the processing of the reg- 55 
ular class which is referred to by the synonymous class 
is facilitated. 

[0127] In an operation of, e.g., selecting a copy or a 



search target of instance data, this embodiment can be 
utilized when directly selecting a target in the GUI. Al- 
ternatively, this embodiment can be used when writing 
a target using a code or a symbol in an operation of writ- 
ing a processing request in an application programming 
interface (API). 

(Tenth Embodiment) 

[0128] This embodiment relates to an embodiment 
showing concrete processing concerning a synony- 
mous class. 

[0129] FIG. 28 is a view showing the relationship be- 
tween a synonymous class and source class. 
[0130] It is determined that class 2 is a synonymous 
class. Source class of class 2 is class 1 1 . Since class 1 , 
class 2 and class 3 have a super /sub hierarchical rela- 
tionship, properties of a super class are inherited. Fur- 
ther, although class 11 is source class of synonymous 
class 2, it is a regular class. Class 11 has class 1 2 as a 
sub-class. 

[0131] The synonymous class and the source class 
independently form hierarchies, import of properties is 
not allowed, and these two types of classes do not in- 
terfere with each other. However, processing with re- 
spect to the synonymous class is executed as process- 
ing with respect to the source class. Furthermore, the 
synonymous class does not have instance data indica- 
tive of regular product information or the like. Even if the 
synonymous class has such data, it is just auxiliary in- 
formation of instance data of the source class. 
[0132] It should be noted that inhibition of import or 
inheritance of properties or the like between the synon- 
ymous class and the regular class is notified to the user 
by displaying a message indicating such inhibition of in- 
heritance or the like when the class edit processing por- 
tion 16 detects an operation in the GUI requesting such 
import or a description in an input/output file. Of course, 
the class edit processing portion 16 does not execute 
data processing including such inheritance or the like. 
[0133] As described above, since the synonymous 
class takes a conformation that it just represents refer- 
ence to the source class, overlapping distribution of in- 
stance data can be avoided as different from a case 
where equivalent classes are prepared by using two dic- 
tionaries. Moreover, in a relationship between a CaseOf 
class which makes reference and a reference class 
which is referred to, although these classes can respec- 
tively create instance data, if there is a change in im- 
ported properties defined in the reference class, there 
is a problem that reflection in the CaseOf class is not 
easy, for example. However, this problem has an advan- 
tage that a change in properties of the class which is 
referred to does not need to be taken into consideration 
by inhibiting creation of instance data and import of 
properties in the synonymous class which makes refer- 
ence. 

[01 34] Although various methods of registering a syn- 
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onymous class in the hierarchical database manage- 
ment system 1 00 according to the present invention are 
described, registration of import properties and usual in- 
stance data can be ignored or rejected with respect to 
the synonymous class in registration in order to provide 
the advantage. 

[01 35] As described above, in this embodiment, a ref- 
erence relationship based on import of properties or par- 
tial inheritance of properties from one dictionary system 
to the other dictionary system is maintained in the two 
dictionary systems, and inheritance of properties is in- 
dependently performed in each dictionary. For example, 
it is assumed that there are dictionary 1 and dictionary 
2 and there are a plurality of sets of properties to be 
inherited. Additionally, it is determined that a parent- 
child(super-sub) relationship between classes is deter- 
mined by using one of the sets of properties, i. e. , a graph 
structure constituting classes belonging to the diction- 
aries is determined. In this case, a property which is re- 
quired to determine this parent-child relationship is re- 
ferred to as a classification property of the dictionary. A 
property P1 imported from dictionary 1 does not affect 
a dictionary structure of dictionary 2 unless property P1 
is incorporated in classification properties of dictionary 
2. In classes, a scheme of dividing properties to be in- 
herited into a plurality of sub-groups and respectively 
inheriting these properties has been already described 
in detail as "inheritance of a plurality of typical 
properties " in Jpn. Pat. Appln. No. 2002-339929. This 
embodiment applies this "inheritance of a plurality of 
typical properties " to a reference relationship of classes 
between different dictionaries. In this case, there are 
provided a technique and structure which uniquely con- 
stitute a class sorting system in a plurality of dictionaries 
while realizing inheritance of properties. 
[01 36] As described above, according to this embod- 
iment, when a regular class has a first property and a 
synonymous class has a second properly, a first inher- 
itance property which is inherited from afirst superclass 
to a first sub-class is set in a first classification system 
including the regular class and, at this time, the first clas- 
sification system can be set to the first sub-class so that 
a second property of the synonymous class is not inher- 
ited. Further, a second inheritance property which is in- 
herited from a second super class to a second sub-class 
is set in a second classification system including the 
synonymous class and, at this time, the second classi- 
fication system can be set to the second sub-class so 
that the first property of the regular class is not inherited. 

(Eleventh Embodiment) 

[0137] This embodiment relates to an embodiment 
utilizing a content view table. 

[0138] FIG. 29 is a view showing various kinds of in- 
formation that a class has. 

[0139] A class has a content table which is a set of 
instance data as well as properties. Besides, the class 



has a set of typical properties, a set of display properties 
and conditions for search or display of instance data 
such as a display condition (a display order or the like), 
a query condition or a security condition. Such a condi- 

5 tion for search or display of instance data (a processing 
condition) will be referred to as a content table view that 
a class has hereinafter. It should be noted that this con- 
tent table view is inherited from a super class to a sub- 
class in accordance with a hierarchical structure like 

10 properties. 

[0140] The typical property is a property which should 
particularly attract the user's attention. This typical prop- 
erty is, e.g., a property which requires or recommends 
input of conditions at the time of search or a property 

f£ which requires or recommends input at the time of reg- 
istration of instance data, but it is different from a key 
property which uniquely identifies instance data. The 
typical property may be displayed differently from any 
other property as described in Jpn. Pat. Appln. No. 

20 2002-339929. For example, it may be displayed with a 
mark given to a property name thereof. 
[0141] The display property means a property which 
is displayed to the user from a property set forming a 
content table. The display condition means, e.g., a dis- 
ss play order in display properties. The query condition 
means a condition which is required to narrow down 
whether instance data is displayed in instance data 
which is an element in the content table. Furthermore, 
the security condition restricts the above-described var- 

30 jous conditions in accordance with each user or group. 
[0142] For example, it is assumed that sets of typical 
properties are PRP001, PRP002 and PRP003, sets of 
display properties are PRP001 , PRP002 and PRP008, 
a query condition is PRP006 >= 512 and a security con- 

35 dition is applied to all members in TableOI shown in FIG. 
27. In this case, these content table views are combined 
with each other, and the content table is displayed to all 
users by the content table view setting processing por- 
tion 17. FIG. 31 is a view showing a display example of 

to this content table view. In the example of FIG. 31 , since 
preference is given to the typical properties over the dis- 
play properties, PRP003 which is included in the set of 
typical properties but not included in the set of display 
properties is also displayed, but preference may be giv- 

45 en to the display properties. 

[01 43] The plurality of content table views may be cre- 
ated with respect to one class by the content table view 
setting processing portion 17, and any content table 
views may be combined with each other and associated 

so with classes. 

[0144] FIG. 32 is a view showing an example of the 
GUI which is used to register a content table view. FIG. 
33 is a view showing an example of a setting file which 
is used to register a content table view. A content table 

55 view may be registered from such a GUI as shown in 
FIG. 32 by the content table view setting processing por- 
tion 1 7, and may be registered by the content table view 
setting processing portion 1 7 using such a setting file as 
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shown in FIG. 33. The setting file shown in FIG. 33 can 
also process a combination of a plurality of types of con- 
tent table views. 

[01 45] FIG. 32 shows an example of a GU I which cre- 
ates a content table view by combining a set of display s 
properties, a security condition and a table content. 
When the user selects a class in a class tree display 
portion 323 in a main screen 321 and selects a content/ 
view creation button 324, the content table view setting 
processing portion 1 7 displays a screen 322 which is io 
used to set a content table view with respect to the se- 
lected class. In the screen 322 in which a content table 
view is set, a list of content tables existing in the selected 
class is displayed in a pull-down menu 325 by the con- 
tent table view setting processing portion 17. The user *5 
determines a content table to be combined by selecting 
one content table. The security condition is set by using 
radio buttons 326a and 326b, and a check-box 327 is 
selected, thereby determine a set of display properties. 
Moreover, a name of the content table view is input in a 20 
text box 328, and an execution button 329 is selected, 
thereby completing setting of the content table view. 
[01 46] By selecting a check box 330, the content table 
view setting processing portion 17 sets the setting data 
as a default content table view, and this data is used to 25 
display the content table even if it is not associated with 
classes. 

[0147] In the typical setting file shown in FIG. 33, set- 
ting of the content table view in which the set of typical 
properties, the display condition of properties (the dis- 30 
play order) and the query condition are combined is per- 
formed, in the file, an identifier of properties and a 
search condition are written as one line, all written prop- 
erties are the set of typical properties, and the written 
order is the display order of properties. When Tabled 35 
shown in FIG. 27 is displayed in accordance with the 
content table view set in this file, the display content is 
as shown in FIG. 31. 

[01 48] FIG. 30 shows an example of the GUI which is 
used to associate the content table view set in FIG. 32 *o 
in which the set of display properties, the security con- 
dition and the table content are combined with the con- 
tent table view set in FIG. 33 in which the set of typical 
properties, the display condition of properties and the 
query condition are combined. The content table view 
set in FIG. 32 is selected in an associating view box 302 
in FIG. 30, and the content table view set in FIG. 33 is 
selected in an associating search view box 303 in FIG. 
30. 

[01 49] The screen shown in FIG. 30 is called from, e. so 
g., class tree display portion 323 after selecting a class 
by the content table view setting processing portion 1 7. 
In this case, the selected class is automatically dis- 
played in the class name box 301 . Further, a set of con- 
tent table views defined in this class is displayed in the ss 
pull-down menu of the boxes 302 and 303, and the user 
is allowed to select a combination, thereby associating 
the respective content table views. Moreover, com- 



mands of delete of each class or content table view, de- 
termination of association, association canceling 
processing are executed by selecting buttons 304 to 
406. 

[0150] As described above, the content table view 
setting processing portion 17 can set the processing 
condition (the content table view) for a synonymous 
class or a regular class, associate the set processing 
condition with a synonymous class or a regular class 
and store it in the association information storage por- 
tion 22, and perform processing of, e.g., displaying a 
synonymous class or a regular class under the stored 
processing condition. That is, by setting indication of a 
synonymous class by using the GUI and inputting/out- 
putting this class to the database in such a manner that 
the synonymous class can be distinguished from a reg- 
ular class, indication of the synonymous class can be 
detected. 

[0151] For example, a condition for selecting a stand- 
ard component or a recommended component in a com- 
pany or any other display condition can be set in the GUI 
or a file. 

(Twelfth Embodiment) 

[01 52] This embodiment relates to an embodiment of 
a concrete technique of setting a synonymous class. 
[0153] FIG. 34 is a view showing a display example 
of a screen which is used for concrete setting of a syn- 
onymous class according to this embodiment. 
[0154] When class Z02 in which a synonymous class 
is created is selected in a class tree display portion 341 
and a synonymous class creation button 343 is select- 
ed, a synonymous class setting portion 342 is displayed. 
A BSU of a synonymous class to be created is input in 
a text box 344 in which a synonymous class BSU is in- 
put. Further, the same name is input in a text box 345 
in which a synonymous class name is input. When a 
class having class code T04 to which reference should 
be made as a synonymous class is selected in class tree 
display portion 341 , source class is automatically dis- 
played in a text box 346 for source class in the synony- 
mous class setting portion 342. 
[0155] When the user selects a button 348, a class 
having class code Z03 is set as a synonymous class. 
Since it is often the case that the BSU which uniquely 
identifies a class does not have a meaning in its char- 
acter string, the synonymous class BSU may be auto- 
matically input in the system. It should be noted that de- 
lete processing and association canceling processing of 
a class or a content table view are automatically execut- 
ed by buttons 347 and 349. 

[01 56] As described above, according to this embod- 
iment, in cases where a synonymous class does not 
have an instance, when indication information required 
to set a synonymous class is input by the input portion 
12, identification information which distinguishes be- 
tween a synonymous class and a regular class can be 
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associated with a class indicated by the indication infor- 
mation. 

[01 57] For example, when a regular class is selected 
as source class, a recommended name in each lan- 
guage of the regular class can be displayed in the GUI 
as a default name of a synonymous class. 

(Thirteenth Embodiment) 

[0158] This embodiment relates to another embodi- 
ment of the concrete synonymous setting technique. 
[01 59] FIG. 35 is a view showing an example of a syn- 
onymous setting portion 351 according to this embodi- 
ment. Any other displayed portion is common to FIG. 
34, thereby eliminating such a portion. That is, in this 
embodiment, like FIG. 34, a class tree display portion 
341 and a synonymous setting portion 351 are dis- 
played. FIG. 35 shows a state in which automatic display 
is performed by selecting a synonymous class creation 
button 343. As shown in FIG. 35, a synonymous class 
name "Personal computer" may be displayed in a text 
box 353 for a synonymous class name in advance in 
order to facilitate input of a synonymous class name. 
Text boxes 352 to 354 and buttons 355 to 357 corre- 
spond to the text boxes 344 to 346 and the buttons 347 
to 349 in FIG. 34. 

[0160] Furthermore, when source class is a synony- 
mous class, a name of this source class may be dis- 
played in the text box 353 for a synonymous class name 
in advance in order to facilitate input of a synonymous 
class name. 

[01 61 ] As described above, according to this embod- 
iment, when a regular class to which reference is made 
by a synonymous class is specified by the input portion 
12, properties of the specified regular class can be dis- 
played as properties of the synonymous class. 

(Fourteenth Embodiment) 

[0162] This embodiment relates to another embodi- 
ment of display of a synonymous class. 
[01 63] FIG. 36 is a view showing an example of a dis- 
play screen according to this embodiment. 
[0164] It is determined that synonymous class "Y01 : 
PC" having a synonymous class Z03 as source class is 
defined. When a synonymous class having class code 
Y01 is selected in a class tree display portion 361 , in- 
formation of "Z03: T company personal computer" which 
is source class of the selected class is displayed in a 
class information display area 362 and a property list 
display area 363. However, the class having class code 
Z03 is a synonymous class, crass information and a 
property list of "T04: Personal computer" which is 
source class of the class having class code Z03 are dis- 
played. 

[01 65] As described above, according to this embod- 
iment, the class edit processing portion 16 can acquire 
a regular class as source class of a synonymous class 



by executing processing of retrieving a class to which 
reference is made by the synonymous class once or a 
plurality of times, and perform processing of displaying 
the regular class to which reference is made by the syn- 
5 onymous class in distinction from any other class. 

(Fifteenth Embodiment) 

[0166] This embodiment relates to an embodiment 

10 utilizing a virtual class called a MY FAVORITES class. 
[0167] FIG. 37 is a view showing an example of dis- 
play of a screen according to the present invention. In 
a class tree display portion 371 are displayed classes 
personally set by the user, i.e., "PC" having source class 

is "Z04: T company personal computer" and "digital cam- 
era" having source class T13: digital camera" like sub- 
classes of a virtual class which is a MY FAVORITES 
class in a class tree. Since there is no point in storing 
the MY FAVORITES class as dictionary information, this 

20 class does not need a class identifier (a class BSU) 
which is necessary for classes based on the IS0 13584 
standards. Further, this class does not have to constitute 
a hierarchy (it may constitute a hierarchy). The setting 
of the MY FAVORITES class may be saved in the client 

25 or the server. 

[01 68] FIG. 38 is a view showing an example of a MY 
FAVORITES setting file. FIG. 38 shows an example in 
which a class hierarchy is not given to a MY FAVORITES 
class in particular. "JA" following a class identifier is lan- 

30 guage specification (Japanese in this example), and a 
MY FAVORITES name can be given in each language 
with respect to a class having a name in each language. 
[01 69] Furthermore, the class edit processing portion 
1 6 converts a MY FAVORITES class into a synonymous 

35 class in response to a request from the user. At this time, 
since the MY FAVORITES class does not need a class 
BSU, the class BSU which is necessary for the synon- 
ymous class may be automatically added in the system 
or the user may be urged to set the class BSU. 

40 [0170] That is, in this embodiment, the class edit 
processing portion 1 6 displays a view showing a MY FA- 
VORITES class which is used to generate a synony- 
mous class in accordance with the user or a group, dis- 
plays a MY FAVORITES class as one of the classes in 

45 the hierarchical database, and stores a inheritance re- 
lationship between the MY FAVORITES class and any 
other class. 

[0171] As described above, this embodiment gener- 
ates a classification in accordance with each user based 

so on existing classes and customizes a view (a presenta- 
tion). It can be said that the class customized for each 
user (which will be referred to as a MY FAVORITES 
class hereinafter) is a classification for the user himself/ 
herself. Therefore, this MY FAVORITES class is drffer- 

55 ent from a reference target standard class (a regular 
class and a synonymous class) in the classification and 
presentation method. In general, information concern- 
ing the MY FAVORITES class does not have to be 
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shared with other users. Therefore, the MY FAVORITES 
class does not need to have a standard code for a class 
or a property which is shared in a given community. 
However, an object which serves as a sign of a class is 
arranged on class tree displayed in the GUI which dis- 
plays a classification system at the user's convenience. 
Moreover, properties or search values which are usually 
used for search are set in the MY FAVORITES class in 
advance. As a result, an intelligible and simple classifi- 
cation can be provided to the user. 
[0172] Of course, the MY FAVORITES class, i.e., a 
personal class can be changed to a synonymous class 
by utilizing information of a regular class to which refer- 
ence is made by this MY FAVORITES class. Alternative- 
ly, when the MY FAVORITES class makes reference to 
a synonymous class, the MY FAVORITES class can be 
changed to a synonymous class by utilizing information 
of a regular class to which the MY FAVORITES class 
makes reference. Alternatively, if a property or a search 
value which is usually used for search exists in common 
with users who belong to a given community or organi- 
zation, such a property or a search value can of course 
be set in a synonymous class as a standard view. 
[0173] For example, the following usage can be con- 
sidered. 

[0174] An icon, a button, a switch, a label and others 
are prepared on a screen as GUI elements for each user 
or group, and a MY FAVORITES object is individually 
generated and displayed for each user. Then, informa- 
tion concerning this MY FAVORITES class can be 
stored and reused. Additionally, this stored data is in- 
serted into and displayed on the classification tree as if 
it is virtually a sorting class. When the user again uses 
the system, the MY FAVORITES class is automatically 
or semi-automatically read and displayed. Further, In- 
formation concerning the MY FAVORITES class is out- 
put to a file and converted into a synonymous class in 
response to a command from the user. Then , insufficient 
information is embedded in advance, and a GUI on 
which the user overwrites and inputs this information is 
prepared. 

[0175] The present invention is not restricted to the 
foregoing embodiments. Although description has been 
given for any example of dictionary information compris- 
ing the classification system complying with a data 
structure based on the PLIB standards, the data struc- 
ture may be partially or completely based on the PLIB 
standards. 

[0176] The present invention is not restricted to the 
foregoing embodiment as it is, and constituent elements 
may be modified and embodied at an embodying stage 
without departing from the scope of the invention. Fur- 
thermore, various inventions can be formed by appro- 
priate combinations of a plurality of constituent elements 
disclosed in the foregoing embodiments. For example, 
some constituent elements may be deleted from all con- 
stituent elements disclosed in the embodiments. More- 
over, constituent elements in different embodiments 



may be appropriately combined with each other. 
[0177] As described above, the present invention is 
effective for the technical field of a hierarchical database 
management system, hierarchical database manage- 
5 ment method and hierarchical database management 
program which manage a so-called hierarchical data- 
base. 

[0178] Furthermore, according to the present inven- 
tion, management between classes of the hierarchical 
10 database can be facilitated. 



Claims 

*5 1 . A hierarchical database, in which a sub-class inher- 
its to a property of a super class, having a class 
code for each class to identify the class, character- 
ized by comprising: 

20 a first classification system having a regular 

class; and 

a second classification system having the reg- 
ular class and a synonymous class referring to 
and using the regular class of the first classifi- 
es cation system, wherein 

the synonymous class has an identification in- 
formation to identify it is the synonymous class, 
a class code of the synonymous class, and a 
class code of the regular class of the first clas- 
30 sification system to which the synonymous 

class refers. 

2. The hierarchical database according to claim 1, 
characterized by further comprising a display unit 

35 which displays the synonymous class which is dis- 
tinguishable from the regular class based on the 
identification information. 

3. The hierarchical database according to claim 1, 
40 characterized in that an Incidental information to 

describe the synonymous class as an independent 
entity to the regular class is associated with the syn- 
onymous class, and further comprises 

a generating unit which generates the synon- 
45 ymous class by reading the identification informa- 
tion described in an input data. 

4. The hierarchical database according to claim 1, 
characterized in that the display unit displays the 

so class code of the regular class as a reference target 
code of the synonymous class, or displays the class 
code of the synonymous class as the synonymous 
classification code of the regular class. 



& 5. The hierarchical database according to claim 1 , 
characterized in that 

the hierarchical database has an import struc- 
ture which imports the class and the property to the 
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first classification system and the second classifi- 
cation system, and has a simple inheritance struc- 
ture in which a sub-class comprises an unique su- 
per class, 

the synonymous class is described by the im- s 
port structure as a class which imports the regular 
class of the first classification system to which the 
synonymous class refers, and the incidental infor- 
mation associated with the synonymous class in- 
cludes information that the class is the synonymous 10 
class, and further comprises 

a processing unit which processes the import 
structure as a multiple inheritance relation that the 
sub-class has two or more super classes. 

15 

6. The hierarchical database according to claim 1, 
characterized In that 

the hierarchical database has a simple inher- 
itance structure that a sub-class has an unique su- 
per class, 20 

the incidental information of the synonymous 
class includes the regular class to which the synon- 
ymous class refers and the information that the 
class is the synonymous class, and further compris- 
es 25 

a processing unit which processes the synon- 
ymous class as a multiple inheritance relation that 
the sub-class has two or more superclasses. 

7. The hierarchical database according to claim 1, 30 
characterized in that 

the synonymous class has no instance, 
the synonymous class is described by the 
special entity newly defined as a specialization of 
the entity which imports the class and the property 35 
of a classification system different from the first 
classification system, and further comprises 

a detector which detects that the synonymous 
class is a synonymous class based on that the syn- 
onymous class is described by the special entity. 40 

8. The hierarchical database according to claim 1, 
characterized in that 

the synonymous class has no instance, and 
the regular class and the synonymous class are de- 
scribed by a first data according to the first classifi- 
cation system, a second data according to the sec- 
ond classification system, and a third data to which 
the synonymous reference information of the first 
classification system and the second classification so 
system are described, and further comprises 

a detector which detects the synonymous 
class based on the synonymous reference informa- 
tion of the third data. 

55 

9. The hierarchical database according to claim 1, 
characterized in that 

the synonymous class has no instance, and 



further comprises. 

a unit which relates the identification informa- 
tion to a class that an instruction information directs 
when the instruction information to set the class to 
the synonymous class is input by an input unit. 

10. The hierarchical database according to claim 9, 
characterized in that the display unit displays the 
class information of the regular class specified with 
the input unit to which the synonymous class refers 
as a first candidate of the class information of the 
synonymous class. 

11. The hierarchical database according to claim 1, 
characterized by further comprising: 

a selector which selects the synonymous class 
displayed on the display unit; and 
a unit which detects selection of the synony- 
mous class, and reads and displays the regular 
class to which the synonymous class refers. 

12. The hierarchical database according to claim 11, 
characterized by further comprising a unit which 
acquires the regular class as a source class of the 
synonymous class by executing a processing of 
searching a reference target class at once or re- 
peatedly when a class to which the synonymous 
class refers is the synonymous class, and executes 
a processing of the regular class to which the syn- 
onymous class refers. 

13. The hierarchical database according to claim 1, 
characterized by further comprising a unit which 
executes a processing of the regular class to which 
the synonymous class refers when detecting an ob- 
ject of an operation with an input apparatus or a data 
processing is the synonymous class based on the 
identification information 

14. The hierarchical database according to any one of 
claim 13, characterized by further comprising a 
unit which acquires the regular class as a source 
class of the synonymous class by executing a 
processing of searching a reference target class at 
once or repeatedly when a class to which the syn- 
onymous class refers is the synonymous class, and 
executes a processing of the regular class to which 
the synonymous class refers. 

15. The hierarchical database according to claim 1, 
characterized in that 

the regular class has a first property, and the 
synonymous class has a second property, and fur- 
ther comprises: 

a first setting unit which sets a first inheritance 
property inherited to first sub-class from a first 
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super class in the first classification system in- 
cluding the regular class, the first setting unit 
further setting the first classification system so 
that the second property is not inherited to the 
first sub-class; and £ 
a second setting unit which sets a second in- 
heritance property inherited to second sub- 
class from a second super class in the second 
classification system including the synony- 
mous class, the second setting unit further set- 10 
ting the second classification system so that the 
first property is not inherited to the second sub- 
class. 

16. The hierarchical database according to daim 1, is 
characterized by further comprising: 

a unit which displays a figures showing a first 
class to generate the synonymous class in a us- 
er or in each group; 20 
a unit which displays the first class as one of 
the classes in the hierarchical database; and 
a unit which stores an inheritance relation be- 
tween the first class and other classes. 

25 

17. The hierarchical database according to claim 1, 
characterized in that 

a unit which sets a processing condition of the 
synonymous class or the regular class; 

a unit which relates the set processing condi- 30 
tion to the synonymous class or the regular class; 
and 

a unit which processes the synonymous class 
or the regular class according to the processing 
condition. 35 

18. A hierarchical database having a class code for 
each class to identify the class, 

characterized by comprising: 

40 

a first classification system having a regular 
class; and 

a second classification system having the reg- 
ular class and a synonymous class referring to 
and using the regular class of the first classifi- 45 
cation system, wherein 

the synonymous class has an identification in- 
formation to identify it is the synonymous class, 
a class code of the synonymous class, and a 
class code of the regular class of the first clas- so 
sification system to which the synonymous 
class refers. 
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create class '14Q/rOPAS2//203'of component_dass( 
supeLdass'ZQ?, 

preferred.name'T company personal computer 1 , 
remark '$SYNONYM-14Qn , OPAS1//.T04 , > 



FIG. 1 6 



create class 't4fl/rOPAS2//Z03'ot component_case_of_dass( 
super_dass'ZQ2\ 

preterred_name'T company personal computer', 
remark '$SYNONYM\ 
is_case_of , 1407rOPAS2//.T04' 



FIG.17 



ENTITY SYNONYMOUS_ITEM_CLASS 
SUBTYPE OF0TEM_CIASS_CASE_OF); 
END_ENTITY; 

ENTITY SYNONYMOUS_COMPONENT_CLASS 
SUBTYPE OF(COMPONEMT_CLASS_CASE_OF); 
END_ENTTTY; 

ENTITY SYN0NYMOUS_MATERIAL_CLASS 
SUBTYPE OF(MATERIAL_CUSS_CASE_OF); 
END.ENTTTY; 

ENTITY SYNONYMOUS_FEATURE_CLASS 
SUBTYPE OF(FEATURE_CLASS_CASE_OF); 
ENDENTITY; 
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#Set Synonymous Class 

#Class Z03: T company personal computer is synonym class 
140/Z_Company//203_001=synonp_dass 

Class Z04: X company personal computer is synonym class 
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PROJECT DEMO 
DEFAULTJYPICALNAME 7YP001 
TOPAS_Demo.14QffOPAS//.T05.PRP001 Value=%Equium & 
TOPAS_Demo.140WPAS//.T05.PRP006 Value>=300 
TOPAS_Demo.14u7TOPAS//.T05.PRP007 30<=Value<=40 
TOPAS_Demo.140/TOPAS//.T05.PRP002 
END 

TYPICAL.NAME TYP002 

END 
END 
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END 
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